Method and system for network resource attack detection using a client identifier

ABSTRACT

Methods, systems, and techniques for network resource attack detection using a client identifier. A server receives from a device the client identifier and user credentials. The client identifier and user credentials are assessed to determine their authenticity. If one or both of the credentials and identifier are inauthentic, the device does not learn from the server which of the identifier and credentials have been found to be inauthentic. When at least one of the identifier and credentials are inauthentic, the device that sent them is assessed to determine whether it is an attacker of the network resource. If the device is determined to be an attacker, one or both of prophylactic and remedial action is taken in response.

TECHNICAL FIELD

The present disclosure is directed at methods, systems, and techniquesfor network resource attack detection using a client identifier.

BACKGROUND

A “network resource” refers generally to a computing resource that isaccessible via a network connection. An example type of network resourceis a mail server accessible using a protocol such as the Simple MailTransfer Protocol (“SMTP”) or the Internet Message Access Protocol(“IMAP”). A “network resource attack” refers generally to any maliciousattempt to compromise security or operation of a network resource.Example types of network resource attacks are “dictionary” and “bruteforce” attacks, each of which attempts to determine the authenticationcredentials of a network resource by repeatedly trying to access thatresource using different guesses of those credentials.

Regardless of the particular type of network resource or networkresource attack, problems related to facilitating network securityremain important, and are arguably increasing in importance, in anincreasingly network connected world.

SUMMARY

According to a first aspect, there is provided a method for networkresource attack detection using a client identifier. The methodcomprises receiving, at a server, the client identifier and usercredentials from a device; determining whether the client identifier anduser credentials are authentic, wherein the device does not learn fromthe server which of the client identifier and user credentials areinauthentic when one or both of the client identifier and usercredentials are determined to be inauthentic; when at least one of theclient identifier and user credentials are inauthentic, determiningwhether the device is an attacker of the network resource; andperforming one or both of prophylactic and remedial action in responseto determining that the device is an attacker.

The client identifier may be representative of a class of devices (e.g.,all Apple™ iOS™ devices, based on a software product key of the iOS™operating system, which is found only on iOS™ devices) or a specificdevice (e.g., a MAC address that is unique to a device).

The client identifier may be representative of a class of users (e.g.,all users having a birthday on a certain date) or a specific user (e.g.,a digital representation of a user's biometric identifier).

The client identifier may be selected from the group comprising a MACaddress of the device; a software license identifier; information storedon a SIM card inserted in the device; a serial number of the device; acar vehicle identification number; a hardware encryption key; a versionof software; a personal identification number; a digital representationof a biometric identifier of the user; and a birthday of the user.

The action may be selected from the group comprising contactingauthorities; adding the IP address of the device to a blacklist; banningor restricting access of the client identifier; banning or restrictingaccess of the user credentials; refusing connections or logins from anyone or more of the IP address, rDNS/PTR, and geographical location ofthe device; creating a database of methods used by the device to connectto the server; publishing data regarding the connection from the device,stealth banning the device; and tarpitting the device.

According to another aspect, there is provided a non-transitory computerreadable medium having computer program code stored thereon to cause aprocessor to perform a method for network resource attack detection asdescribed above.

According to another aspect, there is provided a system for networkattack detection using a client identifier. The system comprises aserver that comprises ports for communication with devices such asclients and attackers, a processor, and a non-transitory computerreadable medium having computer program code stored thereon to cause aprocessor to perform a method for network resource attack detection asdescribed above.

This summary does not necessarily describe the entire scope of allaspects. Other aspects, features and advantages will be apparent tothose of ordinary skill in the art upon review of the followingdescription of specific embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, which illustrate one or more exampleembodiments:

FIG. 1 is a system for network resource attack detection using a clientidentifier, according to a first embodiment.

FIG. 2 is a method for network resource attack detection using a clientidentifier, according to another embodiment.

FIGS. 3 and 4 are examples of computers that can be used as componentsof the system of FIG. 1 and to perform the method of FIG. 2.

DETAILED DESCRIPTION

Different protocols may be used to connect to different networkservices. For example, when the network service comprises a mailtransfer agent (hereinafter interchangeably referred to as a “mailserver”), a client may use a conventional protocol such as SMTP or IMAPto send messages to and receive messages from the mail server. While themail server may be able to determine any one or more of the location ofthe client (e.g., via IP address), the client's credentials (e.g., ausername/e-mail address and password using SMTP AUTH, RFC 2554), andsecurity layers (RFC 4954), being able to identify these characteristicsalone has been relatively ineffective in preventing network resourceattacks, such as dictionary and brute force attacks. For example, ratelimiting, which limits the rate at which an attacker may launch networkresource attacks, also prejudices an authentic user's ability to accessthe network resource and delays, but does not eliminate, the ability ofan attacker to infiltrate the resource. Similarly, using locationdetermination to determine whether to grant access to the networkresource may prejudice an authentic user (e.g., if the authentic user istraveling and accessing the resource from an unexpected location) andmay be bypassed by an attacker (e.g., by using a virtual privatenetwork).

The embodiments described herein are directed at presenting a clientidentifier (“CID”) as part of one or more of methods, systems, andtechniques to authenticate a client and to determine what level ofaccess to grant to the client depending on whether the CID presented bythe client to the network resource is verified/authenticated by, forexample, the network resource or a trusted third party. In combinationwith whether the CID is verified, in some embodiments the networkresource may perform additional actions to determine whether it is beingattacked. For example, the network resource may determine one or both ofthe characteristics of the device that is connecting or attempting toconnect to the network resource and the characteristics of theconnection footprint. Additionally or alternatively, the networkresource may determine whether that device is being used to perform amethod, either alone or together with other devices, that is outside ofthe expected behavior the network resource expects to see from clients.When the network resource determines that an attack is occurring, it cantake appropriate action, such as any one or more of notifying the holderof the accounts under attack that an attack has occurred, notifyingnetwork operators of the source (e.g., IP address) of the attack,blacklisting the IP address from which the attack originated, andnotifying security or law enforcement officials of the attack.

In the following example embodiments, a mail server is used as anexample of the network resource and the client may comprise, forexample, a personal computer or mobile device such as a smartphone. Indifferent embodiments (not depicted), however, the network resource maybe something other than or in addition to the mail server (e.g., a webor file server) and the client may be something other than or inaddition to the personal computer or smartphone (e.g., another server).Additionally, while SMTP and IMAP are used as the communicationsprotocol in the following examples, in different embodiments (notdepicted), different communications protocols (e.g., POP, HTML) may beused.

An excerpt from a log file of a conventional SMTP session between aclient (“C”) and mail server (“S”) is shown below, in which the clientis attempting to attack the mail server:

-   -   Trying 10.10.1.1.    -   1 C: [connection established]    -   2 S: 220 server.example.com ESMTP ready    -   3 C: EHLO client.example.net    -   4 S: 250-server.example.com    -   S: 250-STARTTLS    -   6 C: STARTTLS    -   7 S: 220 Go ahead    -   8 C: <starts TLS negotiation>    -   9 C & S: <negotiate a TLS session>    -   10 C & S: <check result of negotiation>    -   11 C: EHLO client.example.net    -   12 S: 250-server.example.com    -   13 S: 250-AUTH PLAIN    -   14 C: AUTH PLAIN dGVzdABOZXNOADEyMzQ=    -   S: 235 2.7.0 Authentication successful    -   16 C: MAIL FROM:<sender@example.net>    -   17 S: 250 OK    -   18 C: RCPT TO:<receiver@example.com>    -   19 S: 250 OK

In this example, the server is located at IP 10.10.1.1. A connectionbetween the client and server is established (line 1) and the servernotifies the client that it is ready for communication (line 2). Theclient greets the server using EHLO (line 3), indicating that theExtended SMTP protocol is in use, and the server responds (line 4). Theclient and server then negotiate a Transport Layer Security (“TLS”)session (lines 5 to 10) for subsequent encrypted plaintextcommunication. Using the encryption that the TLS session affords, theclient issues another EHLO command (line 11) following which the serveradvertises that it supports SMTP Authorization (“AUTH”) (lines 12 and13). The client presents a hashed version of a user's authorizationcredentials (line 14), which in this case are the user's username (e.g.,e-mail address) and password, following which the server responds thatthe user exists, the password is correct, and access can be grantedbased on the credentials provided (line 15). Mail is subsequentlytransferred from the client to the server (lines 16 to 19).

In this example following establishment of the TLS session, the serverhas access to information such as the client's IP address, thegeographical location corresponding to the client's IP address, certainlimited information regarding the type of operating system used by theclient, the reverse DNS of the IP address (rDNS/PTR), the hostidentifier of the operating system (hostname via HELO), and theregistrant of the client's IP address (via ARIN/whois). However, theserver does not understand whether the client is approved to use any ofthe information it has presented, such as the hashed authorizationcredentials. Furthermore, the server is typically configured topositively or negatively respond to the client depending on whether theclient has presented correct or incorrect authorization credentials;line 15 above shows the server's positive response, while an example ofa negative response is “authentication failed”. This provides anattacker with information regarding whether it has successfullycompromised a user's account. In the example where the authorizationcredentials are a username and password, an attacker is able torepeatedly present different username and password combinations to theserver (e.g., by using a dictionary or brute force attack) until itreceives a positive response to the AUTH command. If the attacker isable to determine at least one of the username and password (e.g., byusing a keystroke logger or sniffing), it can be easier to successfullygain access to the account associated with those credentials. Asdiscussed above, solutions such as rate limiting and using location as afilter for connection requests have their shortcomings. Generally, inconventional systems, actions taken by an attacker to attack a networkresource using dictionary or brute force methods overlap with actionsthat a legitimate user may also take; for example, both a legitimateuser who is traveling and an attacker may attempt to login to thenetwork resource from an unfamiliar IP address, and a legitimate userwho has forgotten his or her password and an attacker may attempt tologin repeatedly using an incorrect password. As described herein, theCID provides a way for the network resource to distinguish between alegitimate user and an attacker.

Referring now to FIG. 1, there is shown an example of a system 100 fornetwork resource attack detection using a CID, according to a firstembodiment. The system 100 comprises a network resource in the form of amail server 104; however, as discussed above, in different embodimentsthe network resource may be a different type of resource, such as a webserver. The server 104 is depicted as having three ports (depicted butnot numerically labeled in FIG. 1) that can be used to exchange mail: anSMTP port, a POP port, and an IMAP port. In FIG. 1, three clients 102a-c (generally, “clients 102”) are communicatively coupled to the SMTPport via a network 106, with the clients 102 and the network 106comprising part of the system 100. The network 106 may be any suitablenetwork for facilitating communication between the clients 102 and theserver 104, such as the Internet or another packet switched wide area orlocal area network.

Also shown in FIG. 1 are multiple attackers 108. One of the attackers108 is using a computer terminal, similar to the clients 102 used byauthentic users, to communicate with the server's 104 SMTP port. Thegoal of this attacker 108 is to use a dictionary or brute force attackto gain access to at least one of the authentic users' mail accounts.

As illustrated in the following examples, the clients 102 and server 104of FIG. 1 implement an SMTP-based protocol that incorporates the CID toreduce the likelihood that any of the attackers 108 will be able toaccess any of the clients' 102 mail accounts.

Example 1

In contrast to the log file of a conventional SMTP session reproducedabove, the following is an excerpt from a log file of an SMTP sessionbetween one of the clients 102 (“C”) and the server 104 (“S”), accordingto one embodiment:

-   -   1 C: [connection established]    -   2 S: 220 server.example.com ESMTP ready    -   3 C: EHLO mycelphone    -   4 S: 250-server.example.com    -   S: 250-CID    -   6 S: 250-STARTTLS    -   7 C: STARTTLS    -   8 S: 220 Go ahead    -   9 C: <starts TLS negotiation>    -   10 C & S: <negotiate a TLS session>    -   11 C & S: <check result of negotiation>    -   12 C: EHLO client.example.net    -   13 S: 250-server.example.com    -   14 S: 250-CID    -   S: 250-AUTH PLAIN    -   16 C: CID MAC fe:45:gj:ha:i6:43:42:j9    -   17 S: 220 Go ahead    -   18 C: AUTH PLAIN dGVzdABOZXNOADEyMzQ=    -   19 S: 235 2.7.0 Authentication successful    -   —OR—    -   S: 503 Unpermitted use of authentication

In this example, after the connection between the client 102 and server104 is established (line 1), the server 104 notifies the client 102 thatit is ready for communication (line 2). The client 102 greets the server104 using EHLO (line 3) and the server responds (line 4) and advertisesthat the server 104 is going to request and verify a CID before anylogin is successful (line 5). The client 102 and server 104 thennegotiate a TLS session (lines 4 to 11) for subsequent encryptedplaintext communication. Using the encryption that the TLS sessionaffords, the client 102 issues another EHLO command (line 12) followingwhich the server 104 advertises that it supports SMTP AUTH and againadvertises that it supports using a CID (lines 12 to 15). The client 102then sends the CID to the server 104 (line 16). In this example, the CIDcomprises a media access control (“MAC”) address of the client's 102network interface card. The server 104 acknowledges receipt of the CIDwithout providing affirmation regarding whether the server 104 hasverified the CID as authentic (line 17). The client 102 subsequentlysends authentication credentials, which in this example are a hashedversion of the user's username and password (line 18). If the server 104is able to authenticate the CID and if the SMTP authenticationcredentials are correct, the server 104 instructs the client that thefollowing which the server responds that the user exists, the passwordis correct, and access can be granted based on the credentials provided(line 19). Alternatively, if any one or more of the CID andauthentication credentials are incorrect, the server 104 instructs theclient that the login is unsuccessful (line 20). In certain differentembodiments (not depicted), in the event the server 104 is presentedwith a CID it cannot verify, the server 104 tells the client 102 thatthe CID cannot be verified.

As noted above, at line 17 the server's 104 response to the client's 102sending the CID (“Go ahead”) does not reveal whether the server 104 hassuccessfully authenticated the CID. In the event that any one or more ofthe CID, username, or password that the client 102 sends to the server104 are incorrect, the client 102 at line 20 does not know which of theCID, username, and password were inaccurate. This may make itsignificantly more difficult for the client 102 to use a dictionary orbrute force attack to gain access to the user's account.

In this example embodiment, the server 104 may have one or more policiesregarding permissible CIDs. For example, the server 104 may have storedin a look-up table a specific list of permissible CIDs. Additionally oralternatively, the server 104 may have stored one or more permissibleclasses or types of CIDs; for example, a device-type restriction may bethat all CIDs that are derived from an Apple™ iOS™ license arepermissible as the server 104 may wish to permit only Apple™ iOS™devices to log in. Additionally or alternatively, the server 104 may usea customer or user-type restriction by recognizing as valid only thoseCIDs derived from an e-mail address of a particular domain or when usedin conjunction with a particular set of user credentials. Additionallyor alternatively, the server 104 may enforce a policy that permits CIDsbased on connection characteristics; for example, the server 104 mayonly recognize as valid those CIDs being used by devices located in acertain geographical region such as the United States. The server 104may overlay any one or more of these policies with each other; forexample, the server 104 may only recognize as valid a CID representativeof an Apple™ iOS™ device that is connecting from the United States, orthe server 104 may only recognize a CID representative of a particularuser or that is used in conjunction with a particular user's credentialswhen the CID also indicates that the connection is originating from aparticular device (e.g., that user's BlackBerry™ phone) or location(e.g., that user's office building).

In the present example embodiment, the server 104 requires the client102 to provide a CID that the server 104 verifies as being authenticbefore permitting the client 102 to successfully log in to the server104; in different embodiments (not depicted), while the server 104 maysupport using a CID, it may not require the client 102 to use the CID.Additionally or alternatively, when the server 104 supports the CID, ifthe client 102 does not submit a CID that the server 104 can verify theserver 104 may grant the client 102 a first tier of access, with asecond and more expansive tier of access available to the client 102only if the server 104 is able to verify the CID.

Additionally, in this example embodiment the CID comprises the client'sMAC address; in different embodiments, the CID may additionally oralternatively comprise a software license identifier (e.g., a productkey for a piece of software), the user's phone number or otherinformation from the user's SIM card, a stored device identifier (e.g.,a device serial number), a car vehicle identification number, a hardwareencryption key, a particular software version, a personal identificationnumber issued specifically for use as the CID, a digital representationof a user's biometric identifier (e.g., fingerprint or voiceprint), auser's birthday, and more generally any identifier that uniquely ornon-uniquely (e.g., for a CID that identifies a class of devices or ageographical area) identifies one or both of the client 102 and theperson or entity using the client 102. An example CID that identifiesthe client 102 and does not directly identify the person using theclient 102 is the client's 102 MAC address and a software product key.Example CIDs that directly identify the person using the client 102 asopposed to the client 102 is information from that person's SIM card anda personal identification number for that person. In one embodiment, theserver 104 may set policies based on how unique the CID is; for example,a CID representative of a particular type of device (e.g., a Microsoft™Surface™ computer) may be treated with less trust that a CIDrepresentative of an individual (e.g., a biometric representation of afingerprint). In this embodiment, the server 104 may be set to morequickly conclude that a device represents one of the attackers 108 morequickly if it is using the device-representative CID as opposed to theindividual-representative CID when all other factors are equal.

Furthermore, while in this example embodiment the server 104 advertisesfor a CID and verifies the CID after receiving it, in differentembodiments (not depicted) the server 104 may advertise for but notverify the CID after receiving it. In some of those differentembodiments, the server 104 may at least require that the client presenta CID before permitting the client 102 to successfully login,notwithstanding that the server 104 may not verify the CID that theclient 102 presents.

Examples 2 through 4, below, are particular examples of the examplemethod 200 for network resource attack detection using a CID as shown inFIG. 2. In FIG. 2, the method 200 begins at block 202 and proceeds toblock 204 where the server 104 receives the CID and user credentialsfrom a device; the device may be one of the clients 102 in the event anauthentic user is attempting to log in to the server 104 or one of theattackers 108. After receiving the CID and user credentials, it isdetermined whether the CID and credentials are authentic (block 206). Ifthe CID and credentials are authentic, the method 200 ends (blocks 208and 212). If one or both of the CID and credentials are inauthentic, itis determined that the device attempting to log in is one of theattackers 108 and one or both of prophylactic and remedial action istaken in response to this determination; examples of prophylactic andremedial action are provided in the following examples. In theembodiments below the server 104 performs blocks 206, 208, and 210,although in different embodiments (not depicted) a third party piece ofcomputing equipment perform any one or more of those blocks.

Example 2

In this example, the interaction between the client 102 and the server104 is identical to that of Example 1 with the exception that the client102 does not submit any CID to the server 104. The server 104 isprogrammed to permit the client 102 to log in only after presentation ofan authenticated CID and hashed username and password; consequently, theclient's 102 AUTH attempt is refused without revealing the existence ofone or both of the username and password and without revealing whetherthe login would have been successful but for presentation of anauthentic CID. This results in the log file generated from communicationbetween the client 102 and server 104 being identical to the log file ofExample 1 with the exceptions that line 16 of the Example 1 log file ismissing and that line 20 of the Example 1 log file is used instead ofline 19.

The server 104 in this example is programmed to store informationrelated to the attempted login; this information may comprise any one ormore of the client's 102 IP address, geographical location (based, forexample, on IP address), operating system type, rDNS/PTR records,network visible identifiers conveyed as part of the connection attempt(e.g., arguments passed with the SMTP HELO command), whether aconnection without a CID was attempted notwithstanding the server's 104policy to require a CID to connect, whether the same user-representativeCID is being used from two different geological locations in apractically impossible manner (e.g., the same CID being used to log infrom Moscow and New Delhi), whether the connection rate the device isattempting to connect at exceeds the rate possible by a human user,whether a discrepancy exists between information provided by the CID(e.g., that the device is running the Windows™ operating system) andinformation collected by other identifiers or means, whether the deviceis presenting a MAC address that is inappropriate for the device,passive operating system fingerprints, the number of network hops usedto make the connection, whether the CID has been used for multipledevices attempting to connect when the CID is device unique such as aMAC address, and the same CID being used to multiple simultaneousconnections when the user associated with the CID has only a single setof user credentials and is already logged in and when the CID is userunique such as a personal identification number. The server 104 may usethis information and analogous or identical information from one or moreof past, simultaneous, and future login attempts to identify a patternto determine whether the communication attempts are from one or more ofthe attackers 108 as opposed to from a legitimate one of the clients102. The information the server 104 uses to make that determination maybe in respect of the same or different CIDs; IP addresses; geographicallocations; usernames, passwords, or other authentication credentials;and any combination of the foregoing.

Once the server 104 has determined that one of the attackers 108 isattempting to login, the server 104 may take one or both of appropriateprophylactic and remedial action. This action may comprise any one ormore of contacting appropriate authorities such as a systemadministrator, regulatory bodies, spam protection agencies, lawenforcement or other government agencies, the American Registry forInternet Number, Internet Corporation for Assigned Names and Numbers,and the attackers' 108 upstream services provider; adding the IP addressof the attacker 108 to a blacklist such as a Realtime Blackhole List;banning or restricting access of any one or more of the CID or othercredentials (e.g., username or password) that the attacker 108 used toattempt to log in from being used in the future; refusing connections orlogins from any one or more of the IP address, rDNS/PTR, andgeographical location of the attacker 108; create a database of theattacker's 108 methods to facilitate identification of the structure ofa botnet used for the attack, so as to gather evidence for legalpurposes; and publish data on the attack (e.g., the IP from which theattack originates, and the networks are locations involved in carryingout the attack); informing other servers that are related to the server104 of the attack, such as other servers in the same cluster as theserver 104; allowing the attacker 108 to continue the attack to continueto gather more information about the attack and the attacker's 108techniques; “hell banning” or “stealth banning” the attacker 108 so thatthe attacker 108 believes the attack is causing harm when it is, infact, not; and tarpitting the attacker 108 to cause the attacker 108 towaste resources in committing an attack that is not harmful. “Refusingconnections” may comprise any one or more of disconnecting the presentconnection and refusing further connection attempts from the attacker108, which may be done by refusing future connections originating fromany one or more of the attacker's 108 IP, geographical location, CID,and device identifier; and refusing future connections made or attemptedto be made in a manner similar to those used by the attacker 108 (e.g.,based on location of any attempted connections). Any refusal of futureconnections may be for an indefinite period, for a set period of time,or until the server 104 has contacted the authorized user of one or bothof the CID and user credentials.

As another example, if the CID is unique to a device and not publiclyaccessible (e.g., based on a token stored on that device and transmittedonly when encrypted, as with the encrypted TLS sessions in the examplesherein) but nonetheless has been used by one of the attackers 108 in anattack, the server 104 may notify the user that the device used in theattack 108 has been compromised and that the device should therefore beone or more of destroyed, investigated, and cleaned.

In a different embodiment, instead of SMTP, a different communicationsprotocol such as IMAP may use the CID to achieve the functionalitydescribed above. For example, the client 102 or attacker 108 may connectto port 993 of the server 104 to communicate using IMAP. Following theclient 102 or attacker 108 submitting the CID, the server 104 checks tosee if the CID is properly formatted; for example, if the server 104 isprogrammed to only accept CIDs that are MAC addresses, the server 104may determine whether the received CID is formatted as a MAC addresswithout substantively attempting to validate the CID. If the CID is inan unaccepted format, the server 104 treats the CID as invalid. If theCID is in an accepted format, the server 104 stores the CID temporarilyin volatile memory and once the server 104 receives user credentialsfrom the client 102 or attacker 108 (e.g., a hashed username andpassword), the server 104 performs a lookup of the stored CID againstauthentic CIDs that the server 104 has stored in association with thoseuser credentials. If the server 104 finds the CID in its list ofauthentic CIDs, the CID is validated as being authentic and, if the usercredentials are also validated, the login is allowed. If the server 104does not find the CID in its list of authentic CIDs, the CID is notvalidated as authentic and the login is refused regardless of whetherthe presented user credentials are authentic. In a different embodiment(not depicted), the server 104 may permanently or temporarily store theCID in non-volatile memory when assessing validation. The server 104 mayvalidate CIDs in non-IMAP embodiments in an analogous manner.

Example 3

In another example, a user may use one of the clients 102 to log in tothe server 104 for the first time, with each of the client 102 andserver 104 supporting use of the CID. The first time the client 102 andserver 104 connect, the client 102 sends a CID to the server 104, and inone embodiment (not depicted) the client 102 sends additionalinformation such as the client's 102 geographical location, IP address,network identifiers, and user identifiers to the server 104. In thisexample, the server 104 permanently stores the CID in non-volatilememory. The user may subsequently access the server 104 (e.g., via acustomer portal) and activate a protection service that the server 104offers and that leverages the CID; activation of this protection serviceresults in all subsequent connections between the user and the server104 requiring submission and validation of this initial CID. Subsequentattempts to log in using this approved CID together with approved usercredentials will be permitted by the server 104; subsequent attemptsusing a different CID, which has not been approved, will not bepermitted by the server 104, even if the other user credentials sent tothe server 104 are correct. As in the above examples, if the CID isincorrect the server 104 does not inform the client whether it is afailure to validate the CID or the other user credentials that resultedin the failed login. Also as in the above examples, various types ofspecific action may be taken in response to a failed login because of anincorrect CID; for example, the source (e.g., IP address) of the client102 attempting to log in may be black listed or otherwise labeled asbeing the IP address of one of the attackers 108. Additionally oralternatively, the server 104 may take action in response to variousother types of information available to the server 104; for example, anyuser presenting the incorrect CID may be forbidden from logging into theserver 104.

In one application of this functionality, the user is a worker who has asmartphone for business use (e.g., a BlackBerry™ phone) and a smartphonefor personal use (e.g., an Android™ phone), and the user's CID is theMAC address of the business smartphone. In this example, regardless ofwhether SIM cards are switched between devices, the user will only bepermitted to access mail via the server 104 if he or she accesses theserver 104 using the business smartphone.

In different embodiments (not depicted), the server 104 may send ane-mail to an e-mail account of the user that the server 104 has on fileafter the user successfully logs in using the CID. In response to thate-mail (e.g., by clicking a link embedded in that e-mail), the user maybe brought to a configuration page the permits the user to configure thepolicy implemented by the server 104 in respect of the CID. For example,the user may configure the server 104 to only permit access to theuser's address book when the CID indicates the user is accessing theserver 104 via a BlackBerry™ phone (e.g., the CID may be that phone'sMAC address). Additionally or alternatively, the CID may represent anapplication on the user's phone or suite of devices (e.g., a product keyindicative of the iOS™ operating system running across the user's iOS™devices), and policy implementation may be based on this different CID.

Additionally or alternatively, the client 102 may self-register a CIDwith the server 104 after first successfully logging in using aparticular set of user credentials in conjunction with a particular CID.For example, the CID may comprise a voiceprint and, at first login, thevoiceprint may be registered as the CID to be used by the server 104 forvalidation purposes going forward. Subsequent successful logins mayconsequently require the client 102 to present the voiceprint to theserver 104. Depending on the configuration of the client 102, this maycomprise, for example, obtaining from the user of the client 102 a voicesample each time the user wants to log in to the server 104, and foreach login attempt presenting that voice sample to the server 104. Theserver 104 may then compare the voice sample obtained for thatparticular login attempt to the voice sample recorded at first loginand, if they match or sufficiently correspond, validate the voice samplefor that particular login attempt as authentic and permit the login tocontinue, assuming the client 102 has also presented valid usercredentials. In a different embodiment (not depicted), theself-registered CID may be presented at a login other than the firstlogin; for example, the CID may be periodically reset, or the user maybe able to log in to a portal that permits user configuration of theCIDs to be accepted as valid by the server 104.

In different embodiments (not depicted), multiple CIDs (e.g., with eachCID corresponding to a different user device) may be associated with asingle user.

In different embodiments (not depicted), the user may also log in to theserver 104 through, for example, the customer portal and view a logshowing attempts that have been made to log in using at least one of theuser's CID and user credentials. The user may, for example, change whichCIDs are authorized and unauthorized. For example, if the user accessesmail through any one of several smartphones that belong to the user'sfamily and the CID for each of the smartphones is that phone's MACaddress, the user may want all the phones' MAC addresses listed asauthorized in order to be able to access mail from any family device. Asanother example, when the CID represents information on a smartphone'sSIM card (e.g., the user's phone number), the user may want to be ableto access the server 104 by swapping the SIM card across devices,regardless of the particular device being used.

Example 4

In this example, the server 104 is managed by an Internet ServiceProvider (“ISP”) that applies various example methods to determinewhether a person attempting to log in to the server 104 is an authenticuser accessing the server 104 via one of the clients 102 or is one ofthe attackers 108.

In a first example method, the server 104 is programmed to only acceptlogins from the clients 102 that present authentic CIDs. The server 104receives login attempts from a particular geographical location (e.g., aparticular IP address, a particular rDNS/PTR, or a particulargeographical area that maps to one or more particular IP addresses) thateither does not present CIDs or that presents inaccurate CIDs. In oneexample, the login attempts repeatedly use one or more CIDs to attemptto log in to different user accounts. When applying the first examplemethod, the server 104 determines whether the device attempting to login has not presented a CID or has presented a CID that the server 104 isunable to verify (i.e., what is considered an inaccurate CID);determines the geographical area associated with that device; and bansor restricts access of all devices from within that geographical area.In one embodiment of the first example method, the server 104 may onlyban or restrict access after receiving a certain threshold number offailed logins from that geographical area; the server 104 mayaccordingly track the number of failed logins from the geographical areaand, when that number exceeds the threshold, then ban or restrict accessof all devices from within that area. In another embodiment of the firstexample method, the server 104 may only ban or restrict access to thosedevices that have attempted to log in using an inaccurate CID. Inanother embodiment of the first example method, the server 104 may usetwo thresholds: the server 104 may ban or restrict access to thosedevices that have attempted to log in using an accurate CID according toa first threshold (e.g., a single failed login attempt) and may ban orrestrict access to those remaining devices in the geographical areadetermined using those devices that have presented inaccurate CIDsaccording to a second threshold that is more generous (i.e., greaterthan) the first threshold.

In a second example method, instead of restricting or banning devicesbased on geographical area the server 104 restricts or bans based ondevice type. For example, after determining that one or more devicesrepresenting the attackers have attempted to log in, the server 104 maysubsequently only allow a certain type of device to successfully log in.The CID may be the product key or another code indicative of BlackBerry™operating system, for example, and the server 104 may only allow CIDsthat are of this type to log in. The server 104 determines that devicesthat do not present BlackBerry™ CIDs are the attackers 108.

In a third example method, the server 104 determines that the same CIDis being presented from multiple locations within a certain time period(e.g., simultaneously, or within a period short enough that it is veryunlikely a legitimate user is using the CID). For example, the server104 may receive login requests that use the same CID, which isassociated with the MAC address of a desktop computer, that originatefrom IP addresses from several states within a period of one hour. Theserver 104 may consequently ban or restrict that CID from future logins.Additionally or alternatively, the server 104 may ban or restrict allfuture logins from the locations (e.g., IP addresses) from which thatCID attempted to log in. As another example, the CID may be adevice-type CID representative of a specific device, and there may be anincrease of a certain number of logins over a certain time for thatdevice (a “spike” in the number of logins) that that is practicallyunlikely (e.g., 5,000 new BlackBerry™ phone activations over the courseof an hour), which the server 104 uses to determine that one or more ofthe attackers 108 is launching an attack.

In a fourth example method, the server 104 counts the number of times alogin is attempted for which the CID and subsequent user credentials donot match. When this number exceeds a certain threshold, the server 104may determine the geographical area associated with the devices thatattempted to log in; and ban or restrict access of some or all of thosedevices from within their geographical areas. Additionally oralternatively, the server 104 may ban or restrict access for all devicesattempting to log in using one or both of the CID and the usercredentials of the failed login attempts.

More generally, the server 104 may determine whether a device attemptingto log in to the server 104 is one of the attackers 108 by applying anysuitable set of rules that are either globally defined and that apply toall devices attempting to log in to the server 104 or that are specificand apply to subsets of those devices based on any one or morecharacteristics such as device type, network resource type, operatingsystem type, CID (e.g., whether the CID is representative of aparticular device, class of devices, a particular user, or a class ofusers), user credentials (e.g., whether those user credentials identifya particular user or class of users), geographical location, rDNS/PTR,number of network hops the client 102 has made to establish aconnection, whether network packets are encoded and the type of anyencoding (e.g., whether encryption exists and, if so, method and versionof encryption), source ports used for the connection, languageidentifiers, and similar criteria. Once the server 104 determines thatone or more of the attackers 108 is attempting to log in by applying allor a subset of the rules, the server 104 then determines what action totake in response. This action again may be based, for example, on anyone or more characteristics such as device type, network resource type,operating system type, CID (e.g., whether the CID is representative of aparticular device, class of devices, a particular user, or a class ofusers), user credentials (e.g., whether those user credentials identifya particular user or class of users), geographical location, rDNS/PTR,number of network hops the client 102 has made to establish aconnection, whether network packets are encoded and the type of anyencoding (e.g., whether encryption exists and, if so, method and versionof encryption), source ports used for the connection, languageidentifiers, and similar criteria.

The embodiments have been described above with reference to flowchartsand block diagrams of methods, apparatuses, systems, and computerprogram products. In this regard, the flowcharts and block diagrams inFIGS. 1 and 2 illustrate the architecture, functionality, and operationof possible implementations of various embodiments. For instance, eachblock of the flowcharts and block diagrams may represent a module,segment, or portion of code, which comprises one or more executableinstructions for implementing the specified logical function(s). In somealternative embodiments, the functions noted in that block may occur outof the order noted in those figures. For example, two blocks shown insuccession may, in some embodiments, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. Some specific examplesof the foregoing have been noted above but those noted examples are notnecessarily the only examples. Each block of the block diagrams andflowcharts, and combinations of those blocks, may be implemented byspecial purpose hardware-based systems that perform the specifiedfunctions or acts, or combinations of special purpose hardware andcomputer instructions.

Each block of the flowcharts and block diagrams and combinations thereofcan be implemented by computer program instructions. These computerprogram instructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing the functionsor acts specified in the blocks of the flowcharts and block diagrams.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions thatimplement the function or act specified in the blocks of the flowchartsand block diagrams. The computer program instructions may also be loadedonto a computer, other programmable data processing apparatus, or otherdevices to cause a series of operational steps to be performed on thecomputer, other programmable apparatus or other devices to produce acomputer implemented process such that the instructions that execute onthe computer or other programmable apparatus provide processes forimplementing the functions or acts specified in the blocks of theflowcharts and block diagrams.

An illustrative computer system 300 in respect of which the methodsherein described may be implemented is presented as a block diagram inFIG. 3. The computer system 300 may, for example, be used as the server104, clients 102, attackers 108, or any combination thereof. Thecomputer system 300 comprises a display 302, input devices in the formof keyboard 304 a and pointing device 304 b, computer 306, and externaldevices 308. While the pointing device 304 b is depicted as a mouse,other types of pointing devices may also be used. In alternativeembodiments (not depicted), the computer system 300 may not comprise allthe components depicted in FIG. 3. For example, when used as the server104, the computer system 300 may lack the display 302, keyboard 304 a,and mouse 304 b.

The computer 306 may comprise one or more processors or microprocessors,such as a central processing unit (“CPU”) 310, which is depicted. TheCPU 310 performs arithmetic calculations and control functions toexecute software stored in an internal memory 312, such as one or bothof random access memory (“RAM”) and read only memory (“ROM”), andpossibly additional memory 314. The additional memory 314 may comprise,for example, mass memory storage, hard disk drives, optical disk drives(including CD and DVD drives), magnetic disk drives, magnetic tapedrives (including LTO, DLT, DAT and DCC), flash drives, programcartridges and cartridge interfaces such as those found in video gamedevices, removable memory chips such as EPROM or PROM, emerging storagemedia, such as holographic storage, or similar storage media as known inthe art. This additional memory 314 may be physically internal to thecomputer 306, or external as shown in FIG. 3, or both.

The computer system 300 may also comprise other similar means forallowing computer programs or other instructions to be loaded. Suchmeans can comprise, for example, a communications interface 316 thatallows software and data to be transferred between the computer system300 and external systems and networks. Examples of the communicationsinterface 316 comprise a modem, a network interface such as an Ethernetcard, a wireless communication interface, or a serial or parallelcommunications port. Software and data transferred via thecommunications interface 316 are in the form of signals which can beelectronic, acoustic, electromagnetic, optical, or other signals capableof being received by the communications interface 316. Multipleinterfaces, of course, can be provided on the computer system 300.

Input to and output from the computer 306 is administered by theinput/output (“I/O”) interface 318. The I/O interface 318 administerscontrol of the display 302, keyboard 304 a, external devices 308 andother analogous components of the computer system 300. The computer 306also comprises a graphical processing unit (“GPU”) 320. The GPU 320 mayalso be used for computational purposes as an adjunct to, or instead of,the CPU 310, for mathematical calculations. However, as mentioned above,in alternative embodiments (not depicted) the computer system 300 neednot comprise all of these elements. For example, the server 104 may lackthe display 302, keyboard 304 a, mouse 304 b, and GPU 320.

The various components of the computer system 300 are coupled to oneanother either directly or indirectly by shared coupling to one or moresuitable buses.

FIG. 4 shows an example networked mobile wireless telecommunicationcomputing device in the form of the smartphone 400. The smartphone 400may, for example, be used as the clients 102, the attackers 108, orboth. The smartphone 400 comprises a display 402, an input device in theform of keyboard 404, and an onboard computer system 406. The display402 may be a touchscreen display and thereby serve as an additionalinput device, or as an alternative to the keyboard 404. The onboardcomputer system 406 comprises a CPU 410 having one or more processors ormicroprocessors for performing arithmetic calculations and controlfunctions to execute software stored in an internal memory 412, such asone or both of RAM and ROM, is coupled to additional memory 414 thattypically comprises flash memory, which may be integrated into thesmartphone 400 or may comprise a removable flash card, or both. Thesmartphone 400 also comprises wireless communication circuitry thatallows software and data to be transferred between the smartphone 400and external systems and networks. In the example embodiment of FIG. 4,the wireless communication circuitry comprises one or more wirelesscommunication modules 424 communicatively coupled to a communicationsinterface 416, which for example comprises a wireless radio forconnecting to one or more of a cellular network, a wireless digitalnetwork, and a WiFi™ network. The communications interface 416 alsoenables a wired connection of the smartphone 400 to an external computersystem. A microphone 426 and speaker 428 are coupled to the onboardcomputer system 406 to support the telephone functions managed by theonboard computer system 406, and GPS receiver hardware 422 may also becoupled to the communications interface 416 to support navigationoperations by the onboard computer system 406. The smartphone 400 alsocomprises a camera 430 communicative with the onboard computer system406 for taking photos using the smartphone 400. Input to and output fromthe onboard computer system 1006 is administered by an I/O interface418, which administers control of the display 402, keyboard 404,microphone 426, speaker 428, and camera 430. The onboard computer system406 may also comprise a separate GPU 420. The various components arecoupled to one another either directly or by shared coupling to one ormore suitable buses.

The term “computer system”, as used herein, is not limited to anyparticular type of computer system and encompasses servers, desktopcomputers, laptop computers, networked mobile wireless telecommunicationcomputing devices such as smartphones, tablet computers, as well asother types of computer systems.

As will be appreciated by one skilled in the art, embodiments of thetechnology described herein may be embodied as a system, method, orcomputer program product. Accordingly, these embodiments may take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware that may all generally bereferred to herein as a “circuit,” “module,” or “system.” Furthermore,embodiments of the presently described technology may take the form of acomputer program product embodied in one or more non-transitory computerreadable media having stored or encoded thereon computer readableprogram code.

Where aspects of the technology described herein are implemented as acomputer program product, any combination of one or more computerreadable media may be utilized. A computer readable medium may comprisea computer readable signal medium or a non-transitory computer readablemedium used for storage. A non-transitory computer readable medium maycomprise, for example, an electronic, magnetic, optical,electromagnetic, infrared, or semiconductor system, apparatus, ordevice, or any suitable combination thereof. Additional examples ofnon-transitory computer readable media comprise a portable computerdiskette, a hard disk, RAM, ROM, an erasable programmable read-onlymemory (“EPROM” or “flash memory”), a portable compact disc read-onlymemory (“CD-ROM”), an optical storage device, a magnetic storage device,or any suitable combination thereof. As used herein, a non-transitorycomputer readable medium may comprise any tangible medium that cancontain, store, or have encoded thereon a program for use by or inconnection with an instruction execution system, apparatus, or device.Thus, computer readable program code for implementing aspects of theembodiments described herein may be contained, stored, or encoded on thememory 412 of the onboard computer system 406 of the smartphone 400 orthe memory 312 of the computer 306, or on a computer readable mediumexternal to the onboard computer system 406 of the smartphone 400 or thecomputer 306, or on any combination thereof; the onboard computer system406 may thereby be configured to perform those embodiments.

A computer readable signal medium may comprise a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. That propagated signal may takeany of a variety of forms such as electro-magnetic, optical, or anysuitable combination thereof. A computer readable signal medium may beany computer readable medium that is not a non-transitory computerreadable medium and that can communicate, propagate, or transport aprogram for use by or in connection with an instruction executionsystem, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, radiofrequency, and the like, or anysuitable combination thereof. Computer program code for carrying outoperations comprising part of the embodiments described herein may bewritten in any combination of one or more programming languages,including an object oriented programming language and proceduralprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (“LAN”) or awide area network (“WAN”), or the connection may be made to an externalcomputer (e.g., through the Internet using an Internet ServiceProvider).

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting. Accordingly, asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises” and“comprising,” when used in this specification, specify the presence ofone or more stated features, integers, steps, operations, elements, andcomponents, but do not preclude the presence or addition of one or moreother features, integers, steps, operations, elements, components, andgroups. Directional terms such as “top”, “bottom”, “upwards”,“downwards”, “vertically”, and “laterally” are used in the followingdescription for the purpose of providing relative reference only, andare not intended to suggest any limitations on how any article is to bepositioned during use, or to be mounted in an assembly or relative to anenvironment. Additionally, the term “couple” and variants of it such as“coupled”, “couples”, and “coupling” as used in this description areintended to include indirect and direct connections unless otherwiseindicated. For example, if a first device is coupled to a second device,that coupling may be through a direct connection or through an indirectconnection via other devices and connections. Similarly, if the firstdevice is communicatively coupled to the second device, communicationmay be through a direct connection or through an indirect connection viaother devices and connections.

It is contemplated that any part of any aspect or embodiment discussedin this specification can be implemented or combined with any part ofany other aspect or embodiment discussed in this specification.

One or more currently example embodiments have been described by way ofillustration only. This description is been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the form disclosed. Many modifications and variations will beapparent to those of ordinary skill in the art without departing fromthe scope of the claims. It will be apparent to persons skilled in theart that a number of variations and modifications can be made withoutdeparting from the scope of the claims. In construing the claims, it isto be understood that the use of a computer to implement the embodimentsdescribed herein is essential at least where the presence or use ofcomputer equipment is positively recited in the claims.

The invention claimed is:
 1. A method for network resource attackdetection using a client identifier, the method comprising: (a)receiving, at a server, the client identifier and user credentials froma device, wherein the user credentials comprise a user identifier andpassword; (b) determining whether the client identifier and usercredentials are authentic, wherein the device does not learn from theserver which of the client identifier and user credentials areinauthentic when one or both of the client identifier and usercredentials are determined to be inauthentic; (c) when at least one ofthe client identifier and user credentials are inauthentic, determiningwhether the device is an attacker of the network resource; and (d)performing one or both of prophylactic and remedial action in responseto determining that the device is an attacker.
 2. The method of claim 1wherein the client identifier is representative of a class of devices.3. The method of claim 1 wherein the client identifier is representativeof a specific device.
 4. The method of claim 1 wherein the clientidentifier is representative of a class of users.
 5. The method of claim1 wherein the client identifier is representative of a specific user. 6.The method of claim 1 wherein the client identifier is selected from thegroup comprising a MAC address of the device; a software licenseidentifier; information stored on a SIM card inserted in the device; aserial number of the device; a car vehicle identification number; ahardware encryption key; a version of software; a personalidentification number; a digital representation of a biometricidentifier of the user; and a birthday of the user.
 7. The method ofclaim 1 wherein the action is selected from the group comprisingcontacting authorities; adding the IP address of the device to ablacklist; banning or restricting access of the client identifier;banning or restricting access of the user credentials; refusingconnections or login from any one or more of the IP address, rDNS/PTR,and geographical location of the device; creating a database of methodsused by the device to connect to the server; publishing data regardingthe connection from the device, stealth banning the device; andtarpitting the device.
 8. A system for network attack detection using aclient identifier, the system comprising: (a) ports for communicationwith devices comprising clients and attackers; (b) a processorcommunicatively coupled to the ports; and (c) a non-transitory computerreadable medium communicatively coupled to the processor, the mediumhaving computer program code stored thereon that is executable by theprocessor and that, when executed by the processor, causes the processorto: (i) receive the client identifier and user credentials from adevice, wherein the user credentials comprise a user identifier andpassword; (ii) determine whether the client identifier and usercredentials are authentic, wherein the device does not learn from thesystem which of the client identifier and user credentials areinauthentic when one or both of the client identifier and usercredentials are determined to be inauthentic; (iii) when at least one ofthe client identifier and user credentials are inauthentic, determiningwhether the device is an attacker of the network resource; and (iv)performing one or both of prophylactic and remedial action in responseto determining that the device is an attacker.
 9. The system of claim 8wherein the client identifier is representative of a class of devices.10. The system of claim 8 wherein the client identifier isrepresentative of a specific device.
 11. The system of claim 8 whereinthe client identifier is representative of a class of users.
 12. Thesystem of claim 8 wherein the client identifier is representative of aspecific user.
 13. The system of claim 8 wherein the client identifieris selected from the group comprising a MAC address of the device; asoftware license identifier; information stored on a SIM card insertedin the device; a serial number of the device; a car vehicleidentification number; a hardware encryption key; a version of software;a personal identification number; a digital representation of abiometric identifier of the user; and a birthday of the user.
 14. Thesystem of claim 8 wherein the action is selected from the groupcomprising contacting authorities; adding the IP address of the deviceto a blacklist; banning or restricting access of the client identifier;banning or restricting access of the user credentials; refusingconnections or logins from any one or more of the IP address, rDNS/PTR,and geographical location of the device; creating a database of methodsused by the device to connect to the server; publishing data regardingthe connection from the device, stealth banning the device; andtarpitting the device.
 15. A non-transitory computer readable mediumhaving program code stored thereon that is executable by a processorcomprising part of a server and that, when executed by the processor,causes the processor to: (a) receive the client identifier and usercredentials from a device, wherein the user credentials comprise a useridentifier and password; (b) determine whether the client identifier anduser credentials are authentic, wherein the device does not learn fromthe server which of the client identifier and user credentials areinauthentic when one or both of the client identifier and usercredentials are determined to be inauthentic; (c) when at least one ofthe client identifier and user credentials are inauthentic, determiningwhether the device is an attacker of the network resource; and (d)performing one or both of prophylactic and remedial action in responseto determining that the device is an attacker.
 16. The non-transitorycomputer readable medium of claim 15 wherein the client identifier isrepresentative of a class of devices.
 17. The non-transitory computerreadable medium of claim 15 wherein the client identifier isrepresentative of a specific device.
 18. The non-transitory computerreadable medium of claim 15 wherein the client identifier isrepresentative of a class of users.
 19. The non-transitory computerreadable medium of claim 15 wherein the client identifier isrepresentative of a specific user.
 20. The non-transitory computerreadable medium of claim 15 wherein the client identifier is selectedfrom the group comprising a MAC address of the device; a softwarelicense identifier; information stored on a SIM card inserted in thedevice; a serial number of the device; a car vehicle identificationnumber; a hardware encryption key; a version of software; a personalidentification number; a digital representation of a biometricidentifier of the user; and a birthday of the user.